Skip to content

feat(sedona-gdal): add dataset and vector/raster wrappers#699

Open
Kontinuation wants to merge 8 commits intoapache:mainfrom
Kontinuation:feat/sedona-gdal-safe-core
Open

feat(sedona-gdal): add dataset and vector/raster wrappers#699
Kontinuation wants to merge 8 commits intoapache:mainfrom
Kontinuation:feat/sedona-gdal-safe-core

Conversation

@Kontinuation
Copy link
Member

@Kontinuation Kontinuation commented Mar 9, 2026

Summary

  • add safe wrappers for GDAL datasets, drivers, raster bands, features, and layers
  • wire the core raster/vector modules that higher-level operations build on
  • keep the wrapper surface explicit by removing module re-export aliases from this layer

Stack

Testing

  • cargo test -p sedona-gdal
  • cargo clippy -p sedona-gdal -- -D warnings

@Kontinuation Kontinuation force-pushed the feat/sedona-gdal-safe-core branch 7 times, most recently from 1c53d55 to efb5606 Compare March 13, 2026 06:38
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR expands sedona-gdal’s safe wrapper layer by adding core dataset/driver abstractions plus initial vector (layer/feature) and raster (raster band) wrappers, forming the foundation for higher-level raster/vector operations.

Changes:

  • Add Dataset and Driver wrappers (open/create/copy, spatial ref, geo-transform, layer creation).
  • Add vector wrappers for Layer/Feature and raster wrapper for RasterBand (+ helpers/tests).
  • Minor test cleanup and new error variant for raster buffer size validation.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 5 comments.

Show a summary per file
File Description
c/sedona-gdal/src/vsi.rs Test assertion tweak for empty buffer representation.
c/sedona-gdal/src/vector/layer.rs New OGR layer wrapper + feature iterator API.
c/sedona-gdal/src/vector/feature.rs New OGR feature + field/geometry helper wrappers.
c/sedona-gdal/src/vector.rs Export newly added vector modules.
c/sedona-gdal/src/raster/rasterband.rs New raster band wrapper (read/write, nodata) + tests.
c/sedona-gdal/src/raster.rs Export raster band module.
c/sedona-gdal/src/lib.rs Expose dataset and driver modules at crate root.
c/sedona-gdal/src/errors.rs Add BufferSizeMismatch error used by raster writes.
c/sedona-gdal/src/driver.rs New driver wrapper + driver lookup + dataset creation helpers + tests.
c/sedona-gdal/src/dataset.rs New dataset wrapper (open, geo/proj, SRS, copy, layer creation, add-band) + tests.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

@Kontinuation Kontinuation marked this pull request as ready for review March 19, 2026 14:48
Copy link
Member

@paleolimbot paleolimbot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

The vector bits seem lightly tested or not tested...unless you need them for something specific I think we should just port them separately (perhaps more closely targeted to exactly what we need to do with them).

Comment on lines +35 to +40
/// A GDAL dataset.
pub struct Dataset {
api: &'static GdalApi,
c_dataset: GDALDatasetH,
owned: bool,
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you expand a little on the ownership here and why we need a non-owned version of this? (I trust that you need this, I have just not seen an owned flag that behaves in this way before).

Comment on lines +195 to +223
/// Fetch the projection definition string for this dataset.
/// Return an empty string if no projection is available.
pub fn projection(&self) -> String {
unsafe {
let ptr = call_gdal_api!(self.api, GDALGetProjectionRef, self.c_dataset);
if ptr.is_null() {
String::new()
} else {
CStr::from_ptr(ptr).to_string_lossy().into_owned()
}
}
}

/// Set the projection definition string for this dataset.
pub fn set_projection(&self, projection: &str) -> Result<()> {
let c_projection = CString::new(projection)?;
let rv = unsafe {
call_gdal_api!(
self.api,
GDALSetProjection,
self.c_dataset,
c_projection.as_ptr()
)
};
if rv != CE_None {
return Err(self.api.last_cpl_err(rv as u32));
}
Ok(())
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we have a wrapper for SpatialRef, do we need these?

Comment on lines +390 to +393
mod tests {
use crate::driver::DriverManager;
use crate::global::with_global_gdal_api;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These tests don't cover any of the vector layer features. Should those features be removed for now (I can work on GDAL vector layer stuff later so we can use it to back a datasource and add the associated tests then)

Comment on lines +30 to +35
/// An OGR layer (borrowed from a Dataset).
pub struct Layer<'a> {
api: &'static GdalApi,
c_layer: OGRLayerH,
_dataset: PhantomData<&'a Dataset>,
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless you need this for the raster work I think we should remove it for now. The options exposed by georust/gdal are not really sufficient for what we would need to do with them to make use of this (and we need a different ownership model so that we can return Box<dyn RecordBatchReader>). I'm happy to port over the vector stuff later.

Comment on lines +30 to +35
/// An OGR feature.
pub struct Feature<'a> {
api: &'static GdalApi,
c_feature: OGRFeatureH,
_lifetime: PhantomData<&'a ()>,
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless you need this for raster work I think we can port this separately as well. We would almost certainly use the Arrow interface instead of the feature interface.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants